1. Field of the Invention
This invention generally relates to distributed multi-channel instance computer systems, and more specifically, to a configuration for messaging multiplexed channel instances with varying connection speeds in such systems.
2. Background Art
Distributed computing systems are in common use today, as they offer many important advantages, including large capacity, quick response, distributed workloads, high reliability and extensive resources and functionalities. In these systems, a number of client applications, running on one or more client computers or stations, communicate with a number of server applications, running on one or more server computers.
A number of communications channel instances are provided for handling the communications between the client and server applications; and when a client application requests access to a server application, one of those channel instances is selected to handle the communications traffic between the two applications. With current technology, a single channel instance can handle communications in both directions between a client and a server, and, in fact, one channel instance can handle communications in both directions between multiple clients and a server. This technology increases very substantially the amount of communications that can be handled by a given number of channel instances.
When single channel instances handle communications between plural clients and a server, selecting the appropriate channel instance for the communications between a client and a server may be difficult because different communication streams require different protocols. Once a specific protocol is established for a given channel instance; only communications that can be handled using that protocol can be added to that channel instance.
Application connections from a messaging client may be multiplexed over a single communications channel instance, such as a TCP/IP socket. The first application connection on a particular channel instance causes the protocol set-up (e.g. socket) flows to occur, which are followed by other flows which determine the nature of the connectivity on that messaging channel instance/socket. For instance, the value of a messaging heartbeat interval may be negotiated at this stage (the heartbeat being sent on an idle channel instance to check for connectivity problems). Another example of these subsequent flows may involve an SSL handshake, which allows for mutual authentication of the parties at both ends of the channel instance, and sets up algorithms for subsequent data encryption and data hashing.
Subsequent application connections can only multiplex on to a particular channel instance if the channel instance characteristics, such as SSL connectivity, specified for the connection match those specified on that channel instance. They can also only multiplex on to a channel instance if that channel instance supports multiplexing and has not reached its multiplexing limit. So once the first connection on the channel instance has completed its connection flows, a new matching connection will multiplex with it provided that the channel instance is configured to support multiplexing after its initial flows are complete.
The problem with this scenario is that while channel instances are first connecting there can be a significant delay, for instance SSL negotiation is very processing-intensive, slow lines may be involved to transmit the negotiation flows, overloaded systems may not respond promptly, connection attempts to invalid destinations can be particularly lengthy. If an attempt is made to make a new connection with characteristics which match one which is still in the process of connecting, it is impossible to tell immediately whether this can be multiplexed on this channel instance or not.
U.S. patent application Ser. No. 12/248,069, for “Method and System For Efficient Selection Of A Messaging Multiplexed Channel instance,” filed herewith, describes the behavior of a new connection attempt in a multiplexed messaging system which matches an existing communications channel instance which is in the process of establishing its initial connection. Providing it does not exceed a predetermined multiplexing limit for that channel instance, the new connection attempt is queued waiting for the channel instance to complete its initial flows, at which stage the waiting connection is prompted to search for a channel instance to multiplex on again, and in general it will use the newly connected channel instance.
With this procedure, the particular waiting connection may be subject to delays, such that the queued new connections are kept waiting for a time, when instead they could move on to a new channel instance instance/socket and connect on that. In many systems this is probably not an important issue and the approach described in U.S. patent application Ser. No. 12/246,069 provides excellent results. Moving on to a new channel instance instance/socket tends to reduce the level of multiplexing, and in many systems the new channel instance will attempt to connect across the same network path to the same remote destination using the same connection flows (e.g. SSL) and so probably will not be any quicker than the one the new connection was waiting on.
In some systems, however, new channel instance instance/socket connection attempts may vary greatly in their connection speed. This can happen even when the channel instances are attempting to connect to the same remote system if a complex routing configuration, potentially involving slow lines, lies between the two systems. It is even more likely in a workload balancing situation, in which the channel instances are routed to several different, identical server systems, and which may involve routing connection flows over quite different communications networks to reach one remote server rather than another.
One possible approach to this problem would be to impose a fixed system-specified time-out when a new connection is queued waiting to multiplex, after which it moves on to connect on a new channel instance.
This does improve the situation in the case of excessive delays, but has the clear drawback that it has to be chosen for the average case. In some systems with very fast connectivity, an average delay will be regarded as unacceptable. In other systems, long connection times may be the norm, so with this approach switching to a new channel instance might occur when the original connection attempt was still progressing normally.